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Application No. 10/700,995 



REMARKS 

The Office Action mailed October 6, 2006 has been reviewed and the comments therein 
were carefully considered. Claims 1-21 are currently pending. Claims 1-21 stand rejected. 

Objections to the Specification 

On page 2 the Office Action objects to the use of "a table being included in an XML 

file." The Office Action suggests that a table being included in an XML file: 

. . is not commensurate with the XML table data in view of its implementation as 
described in other parts of the Specifications, and does not come in agreement 
with the more commonly accepted meaning of a table and that of a markup 
language is understood by one skill in the art, according to which, a market page 
does not reasonably contain a table. There is no explicit teaching in the Specs 
about the term 'table' in terms of defining how the table being included in an 
XML format (i.e. text being markup having tags) would amount to, i.e., it being 
provided in some format that would make it particularly distinguishable from a 
standard table as perceived from general meeting. 

The Office Action then suggests that what is disclosed as a table "appears to be a tabular 
set of data being formulated into markup text; and the table is not practically a table being 
included but externally provided tabular data source being integrated inside a markup form." 

The Applicant requests that the Office reconsider the objection to specification. Figure 3, 
as referenced by the Office Action, provides an explicit example of what is meant when the 
application describes a table being included within an XML file. The Applicant respectfully 
submits that Figure 3, and the rest of the application, make it abundantly clear what is meant by a 
table being included within an XML file. Moreover, the Applicant does not believe that the 
Applicant's use of "table" is inconsistent with how the term is used in the art. For example, 
Microsoft Press Computer Dictionary, Third Edition of 1997 includes the following definition of 
table: 
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1 . In programming, a data structure usually consisting of a list of entries, each 
entry being identified by a unique key and containing a set of related values. A 
table is often implemented as an array of records, a linked list, or (in more 
primitive languages) several arrays of different data types, all using a common 
indexing scheme. . . 

The Applicant respectfully requests that the objection to specification be withdrawn. 

Claim Rejections Under 35 USC §112 

Claims 7-9 and 20-21 stand rejected under 35 USC §112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. Claims 8-9 stand rejected for failing to remedy claim 7. 

Beginning on page 3, the Office Action rejects several claims under 35 USC §112, 
second paragraph as being indefinite because of the use of limitations relating to a table inside of 
a file. The Office Action suggests that "[o]ne skill in the art, for lack of precise, explicit 
definition and teaching in the Disclosure concerning the table as recited, will treat this limitation 
as mere tabular like or tabular related data." Again, the Applicant respectfully suggests that 
Figure 3 provides an explicit example which illustrates exactly how the Applicant is using the 
term "table" in relation to an XML file. At the bottom of page 3, the Office Action appears to 
suggest that the claims are indefinite "absent any teaching about the markup language defining 
the layout or physical implementation of a 2-dimensional table." However, none of the claims in 
the present application include "2-dimensional dimensional table" limitations. Moreover, as 
used in the present application, "table" describes a data structure. 

For at least these reasons, the Applicant respectfully submits that claims 7-9 and 20-21 
are definite and in compliance with 35 USC §1 12, second paragraph. 
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Claim Rejections Under 35 USC §101 

Claims 1-4, 6-10, 12-14 and 16 stand rejected under 35 USC §101 because the claimed 
invention is directed to non- statutory subject matter. 

Claim 1 is drawn to a "computer-readable medium having thereon a data structure." On 
page 4 the Office Action alleges that claim 1 "amounts to a product comprising descriptive 
software entities stored thereon." The Applicant respectfully disagrees. Claim 1 is drawn to a 
computer-readable medium having "functional descriptive" material stored thereon. See page 50 
of the Interim Guidelines for Examination of Patent Applications for Patent Subject Matter 
Eligibility. On page 50 the Interim Guidelines discuss In re Lowry , which held that claims to a 
data structure stored on a computer readable medium that increases computer efficiency are 
statutory. Claim 1 includes such a data structure stored on a computer-readable medium and 
having elements listed in particular orders to increase computer efficiency. For at least this 
reason, The Applicant respectfully submits that claim 1 and dependent claims 2-4 are in 
compliance with 35 USC §101 . 

Claim 6 has been amended to include the feature of "testing a software module with the 
parameter value combinations." Claim 6 and the claims that depend from claim 6 are now 
believed to be in compliance with 35 USC §101. 

Claim Rejections Under 35 USC §102 

Claims 1-10, 12-14 and 16-19 stand rejected under 35 USC §102(e) as being anticipated 
by US Publication No. 2004/0128584 ("Mandava et al."). 

Mandava et al. discloses a method for analyzing the test coverage of a software 
application specification by a test suite. As described in paragraph 38, the method is used to 
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determine whether assertions that are included in a specification document are complied with. 
As shown in figure 1A, a software specification includes numerous assertions. The system and 
method disclosed in Mandava et al. allows the user to determine which assertions are tested with 
a testing process. Figure 3G, for example, lists individual test suites and assertions that are 
tested by those test suites. With this system a user can look at column 358 and realize that 
several assertions that are included in the software specification are not tested at all and then take 
appropriate action. 

In contrast to what is disclosed in Mandava et al., claim 1 is drawn to a computer- 
readable medium having thereon a data structure identifying parameter value combinations for 
use to test a software module. Claim 1 further includes the feature of "a first section that 
includes a set of testing parameters listed in a parameter order." The Office Action suggests that 
this feature is found in Mandava et al. in Table 1 and paragraphs to 68-70. The Applicant 
respectfully disagrees. Table 1 illustrates an exemplary representation of assertions found in an 
assertions document. See paragraph 66. Paragraphs 68-70 describe elements of the assertion 
document. There it is no disclosure of "a set of testing parameters listed in a parameter order." 
Claim 1 further includes the feature of "a second section that includes a first set of parameter 
values listed in an order such that each value is positioned in the same order as the corresponding 
parameter is listed in the parameter order." On page 6 the Office Action alleges that this feature 
is found in Mandava et al. in paragraphs 71 and 74. The Applicant respectfully disagrees with 
the characterization of paragraphs 71 and 74. In particular, it is unclear how paragraphs 71 and 
74 can be considered as disclosing "parameter values" that are position in the same order as the 
corresponding parameter is listed in the parameter order. Paragraphs 71 and 74 describe an 
assertion document that contains assertions and not parameter values. 
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For at least these reasons, the Applicant respectfully submits that claim 1 is not 
anticipated by Mandava et al. and is a condition for allowance. The claims that depend from 
claim 1 are allowable for at least the same reasons as claim 1 . 

Claim 6 includes the feature of "extracting parameter value combinations from a data file 
marked up with a markup language." On page 7, the Office Action alleges that this feature is 
found in figures 3D-1,2,3 and figures 3F-1 and 2. Figures 3D-1,2,3 merely illustrate the 
assertion documents corresponding to specification. See paragraph 155. The assertions are not 
parameter value combinations. Figure 3F-1 illustrates a static XML file that shows a listing of 
assertions that are tested by different tests suites. See paragraph 157. The files shown in figures 
3F-1 and 2 may be used to create the display shown in figure 3G, which allows a user to view 
and determine which assertions are tested by which testing suites. See paragraph 160. 

For at least these reasons, the Applicant respectfully submits that claim 6 and the claims 
that depend from claim 6 are not anticipated by Mandava et al. and are in condition for 
allowance. 

Claim 17 includes the feature of "an import component that extracts parameter value 
combinations from a data file marked up with a markup language." On page 8, the Office Action 
alleges that these features are found in figures 3D-1,2 and 3 and 3F-1 and 2. Figures 3D-1,2 and 
3 and 3F-1 and 2 have been described above in this response and do not disclose "an import 
component that extracts parameter value combinations from a data file marked up with a markup 
language." 

For at least these reasons, the Applicant respectfully submits that claim 17 and the claims 
that depend from claim 17 are not anticipated by Mandava et al. and are in condition for 
allowance. 
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Claim Rejections Under 35 USC §103 

Claims 11,15 and 20-21 stand rejected under 35 USC §103(a) as being unpatentable over 
Mandava et al, and further in view of U.S. Publication No. 2003/0163802 ("Takahashi"). 

Claims 11 and 15 are allowable for at least the same reasons as the claims from which 
they depend. 

Claim 20 includes the feature of "receiving at a spreadsheet application a plurality of 
parameter value combinations." On page 10 the Office Action suggests that Mandava et al. 
discloses receiving a plurality of parameter value combinations in figure 1 B-l, table 5, and 
paragraphs 119 and 121. Figure 1 B-l has been described above and merely discloses a listing of 
assertions. Table 5, shows an exemplary assertion rule. Paragraphs 119 and 121 discuss 
assigning keywords to an assertion. The Office Action does not provide any indication of what 
is considered a parameter, or a parameter value in the cited sections of Mandava et al. If this 
rejection is maintained, the Applicant respectfully requests that the Office specifically identify 
where Mandava et al. discloses a "parameter" and "a plurality of parameter value combinations" 
so that the Applicant will have an opportunity to respond to the rejection. 

The Office Action admits that Mandava et al. does not disclose receiving parameter 
combinations from a spreadsheet and then references the discussion of claim 11. On page 9, the 
Office Action suggests that it would have been "obvious for one skill in the art to implement the 
chapter and table specification of Mandava as mentioned above so that they are spreadsheet data 
- as these are analogized to the 2D tables of parameter definitions by Takahashi." The 
motivation provided than discusses dynamic updating of data cells. The Office Action has failed 
to provide any explanation of why one skilled in the art would have been motivated to 
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dynamically update the data of cells with a proposed modification of Mandava et al. In 
particular, there is no suggestion in Mandava et al. that any cells need to be dynamically updated 
and it is unclear why one skilled in the art would want to dynamically update any of the data 
shown in Mandava et al. The Applicant accordingly submits that the Office Action has failed to 
establish a prima facie case of obviousness. 

For at least these reasons, the Applicant respectfully submits that claim 20 and dependent 
claim 21 are patentable over Mandava et al. and Takahashi. 

Objections to the Oath/Declaration 

A new Declaration is being filed along with this response. Reconsideration of the 
objection is requested. 

Conclusion 

Applicants therefore respectfully request reconsideration of the pending claims and a 
finding of their allowability. A notice to this effect is respectfully requested. Please feel free to 
contact the undersigned should any questions arise with respect to this case that may be 
addressed by telephone 

Respectfully submitted, 

Date: February 6, 2007 By: /Charles L. Miller/ 

Charles L. Miller 
Registration No. 43,805 
Banner & Witcoff, Ltd. 
10 South Wacker Drive 
Suite 3000 
Chicago, IL 60606 
Telephone: 312-463-5000 
Facsimile: 312-463-5001 
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